1. Field of the Invention
This invention relates to computer systems and, more particularly, to data transmission over computer networks.
2. Description of the Related Art
Many business organizations provide services that require transmission of large volumes of data to customers over communication networks such as intranets or the Internet. For example, multimedia providers may need to transmit audio and video files on demand from centralized or distributed servers to hundreds or thousands of clients. As the usage of broadband connections to the Internet increases, the demand for consumer multimedia applications such as video and audio subscription services is expected to continue growing rapidly. Within corporate intranets, where high bandwidth interconnects such as dedicated T1 lines may often be deployed, other multimedia applications such as video conferencing, long distance education (e.g., using taped versions of courses), broadcasts of company events to worldwide locations, and the like are quickly becoming more popular. In each of these kinds of applications, large amounts of data (e.g., from tens of megabytes to several gigabytes), which may typically be stored within a single file or a set of files, may need to be transmitted to a large number of clients.
Frequently, file transmission is performed using one or more protocols of the TCP/IP (Transmission Control Protocol/Internet Protocol) family of network protocols. For reliable transmissions, a connection-oriented protocol such as TCP may be employed. However, TCP and other reliable protocols may not be best suited for transmission of data for some kinds of applications where some level of packet loss may be tolerated. Reliable connection-oriented protocols like TCP automatically perform flow control and congestion control, for example by shrinking window sizes in response to a detection of congestion or packet loss. Thus, for example, if a few packets of a video file are lost during a transmission over a reliable connection-oriented protocol, the networking software implementing the protocol at the server may throttle the flow of subsequent packets, and may even stop transmitting data packets under certain conditions. Such automatic throttling of data transfer may result in unacceptable delays and interruptions at the client. Instead of demanding guaranteed in-sequence transmission for each and every packet of an audio or video file, in many cases audio and video client playback applications may accept a certain rate of packet loss, as long as new packets keep arriving, allowing playback to continue even if a few frames of a video or a few notes of an audio recording are lost.
As a result of the potentially undesirable consequences of transmitting audio or video data over connection-oriented protocols like TCP described above, many multimedia applications may be configured to use connectionless and potentially unreliable protocols like UDP (User Datagram Protocol) instead. A connectionless protocol may provide unreliable delivery of data packets using a protocol like IP to transport messages between machines. Packets sent over a connectionless protocol may be lost, duplicated, delayed, or delivered out of order. A server expects no explicit acknowledgments at the protocol level when it transmits data over a connectionless protocol. Consequently, networking software at the server may often be configured to ignore packet loss, network congestion and other similar problems. Instead of throttling data transmission of a video or audio file in the presence of errors, a server using a connectionless protocol may simply continue with transmissions of subsequent packets, which may often be the desired behavior from the point of view of video or audio playback applications at the clients.
Traditionally, however, the use of connectionless networks such as UDP for file transmission has been hampered by a number of factors. A single server application may be responsible for serving files to numerous clients, and may have to manage the scheduling of packets for each client separately at the server application level. In many applications, different clients may have different performance requirements, further complicating the scheduling tasks that may need to be performed at the server application. Packet scheduling may have to be implemented by the application using operating system provided timers or other mechanisms that may require one or more system call invocations for the scheduling of each packet. Interrupts and context switches generated due by timer expirations or timeouts related to application-level scheduling may further reduce the scalability of the application. In addition, the server application transmitting the multimedia file may typically have to subdivide the file into small segments, initialize a packet header including the client's address for each segment, and send each segment using a separate invocation of another system call. Further, each segment of the file to be transmitted may have to copied twice at the server: first, the segment may be copied from a storage device such as a disk into a buffer in the application's address space, and then, the segment may be copied from the buffer into an operating system kernel address space for transmission over the connectionless protocol. As the number of clients concurrently handled by a given multimedia server or other file provider increases, the complexity for the server application of simultaneously managing multiple transmissions, and the processing costs incurred by the application (e.g., for packet scheduling, generating packet headers, transmitting each packet individually, and multiple copies for each segment of data) may both increase to prohibitive levels.